Server in internet-of-things communication path

ABSTRACT

Radio networks such as Public Land Mobile Networks (PLMNs), user equipment devices (UEs), servers such as Internet-of-Things servers, and core network entities may be adapted to facilitate transfers of connections of wireless devices. For example, a first PLMN may provide restricted access to a UE to assist the UE in finding a second PLMN for a full connection. Entities may be adapted to support for non-coverage related PLMN transfers, such as transfers initiated by UEs, PLMNs, servers, and core network entities, e.g., in response to changing usage, congestion, etc.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/049,766 filed Oct. 22, 2020 which is the National Stage Applicationof International Patent Application No. PCT/US2019/031704, filed May 10,2019, which claims the benefit of U.S. Provisional Application No.62/669,669, filed May 10, 2018, entitled “Server in Internet-of-ThingsCommunication Path”, the contents of which are hereby incorporated byreference in their entireties.

BACKGROUND

This disclosure pertains to Public Land Mobile Network (PLMN) selectionand switching in machine-to-machine (M2M), Internet-of-Things (IoT),web-of-things (WoT) systems, and the like, such as those described in3GPP TS 23.501, System Architecture for the 5G System; Stage 2, v15.0.0;TS 23.502, Procedures for the 5G System; Stage 2, v15.0.0; TS 23.122,Non-Access-Stratum (NAS) functions related to Mobile Station (MS) inidle mode, v15.2.0; RP-172021, Study on NR-based Access to UnlicensedSpectrum; and 3GPP TS 21.905 Vocabulary for 3GPP Specifications, V14.1.1.

SUMMARY

Radio networks, such as Public Land Mobile Networks (PLMNs), may beadapted to facilitate transfers of connections of wireless devices.Further, a radio network may be adapted to support for non-coveragerelated PLMN transfers.

For example, the first radio network may be adapted to receive a requestfrom a user equipment (UE) or from a second radio network to initiatethe transfer of one or more devices from one radio network to another.Further, the first radio network may send a request to a user equipmentor to a second network to initiate the transfer of one or more devicesfrom one radio network or another.

A radio network may support devices by providing restricted access forthe purposes of assisting in network selection. For example, a devicesuch as a user equipment, may receive system information related tonetwork support for restricted access for network selection assistancefrom a first network. The device may then send a modified registrationrequest to the first network. The device and the first network usesignaling to establish a limited registration, e.g., to allow access tothe first network for the limited purpose of finding, and transferringto a second network.

User equipment, and servers such as IoT servers, may also be adapted tofacilitate radio network transfers. For example, a user equipment maysend a manual network selection request to a server over a first networkwhere the request containing a list of networks found by the UE. Theserver may then send a manual network response to the user equipment,response from the IoT server containing indication to connect to asecond network, e.g., wherein second network is from the list ofnetworks supplied by the user equipment. The UE may then de-registerfrom the first network and register with the second network.

A manual network selection request may, for example, include one or moreof: a list of networks (PLMN/RAT combinations) the user equipment hasfound; received signal strength or other metrics for each network; acell identity of strongest cell for each network; and an address of anIoT server to contact.

A manual network selection request or response may, for example, be sentvia modified Non-Access-Stratum (NAS) control message, embedded inregistration request or response message, or sent over an IP connectionto an IoT server.

For example, a UE may register with a first network and signal supportfor non-coverage related PLMN transfers. The UE may then receive arequest from an IoT server to perform a network search. The UE mayperform the search and send a list of found networks to the IoT server.The UE may receive a PLMN update request to transfer to a secondnetwork, wherein the second network may be on the list of foundnetworks. The UE may then de-register from the first network andregister with the second network. The PLMN update request may, forexample, include: an activation time for when to de-register from thefirst network and register to the second network; and a time window overwhich the UE should de-register from the first network and register tothe second network.

A core network entity, such as an apparatus implementing a networkfunction, may be adapted to facilitate PLMN transfers. For example, acore network entity may make a determination that one or more UEs,served by an IoT server, should to be transferred to another network.The entity may then send a UE transfer request to the IoT server,requesting assistance in transferring the UEs. The UE may receive a UEtransfer response from the IoT server, with a list of UEs to transferand the target network for these UEs. The entity may then send aPLMNUpdate request to the UEs on the list.

Such operations of the core network entity may be implemented in anumber of ways. For example, the determination is based on: a UL load, aDL load, a buffer load, or a signaling load, or some combinationthereof. The UE transfer request may include, for instance: a list ofUEs, locations of UEs, UE network loads, and a reason for the transferrequest.

IoT servers may be adapted to facilitate PLMN transfers in a number ofways. For example, IoT servers may request context information from IoTApplication Servers, UEs, and networks. An IoT server may evaluatewhether a PLMN transfer is warranted, e.g., based on received contextinformation. The server may determine that a UE on a first networkshould be transferred to an alternative network. The server may thensend a UE transfer proposal to the alternative network, in order todetermine whether the alternative network is willing to accept theregistration of the UE. If so, the server may send a UE transfer requestto the UE through the first network. For example, the evaluation by theIoT server may be based on transferring UEs to the alternate network tominimize the IoT server communication, or to and take advantage ofmulticast capability of a radio network.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter. Furthermore,the claimed subject matter is not limited to limitations that solve anyor all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE FIGURES

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawings.

FIG. 1 is a block diagram of an example set of entities in cellular andpacket networks.

FIG. 2 is a block diagram of an example IoT cellular deployment.

FIG. 3 is a block diagram of an example set of entities involved in homerouted roaming.

FIG. 4 is a block diagram of an example set of entities involved inlocal breakout roaming.

FIG. 5 is a block diagram of an example congestion use case.

FIGS. 6 and 7 show a call flow of an example method for PLMN selectiontriggered by an M2M/IoT Device.

FIGS. 8-10 show a call flow of an example method for PLMN reselectiontriggered by a core network.

FIGS. 11-14 show a call flow of an example method for PLMN reselectiontriggered by an M2M/IoT server.

FIG. 15 shows example roaming alternatives.

FIGS. 16-18 show a call flow illustrating an example method for PLMNreselection to a non-roaming—visited routing PLMN)

FIG. 19 illustrates example graphical user interfaces.

FIG. 20 illustrates an example communications system.

FIGS. 21, 22, and 23 are system diagrams of example RANs and corenetworks.

FIG. 24 illustrates another example communications system.

FIG. 25 is a block diagram of an example apparatus or device, such as aWTRU.

FIG. 26 is a block diagram of an exemplary computing system.

DETAILED DESCRIPTION

Herein, the term “device registration” refers to methods by which adevice creates a signaling connection with the PLMN's core network.Device registration may be accomplished through an ATTACH REQUEST in 4Gnetworks and through a REGISTRATION REQUEST in 5G networks. Deviceregistration allows a UE to connect to a mobile network and receiveservices from that network. Device registration is sometimes referred toas “device association” or “device attachment.”

Herein, the term “M2M/IoT application” refers to an application thatremotely controls/monitors/configures an M2M/IoT device. This istypically done through the aid of services provided by the M2M/IoTServer and through a wireless cellular network, if these devices arecellular. 3GPP typically refers to such applications as ApplicationServers (ASs).

Herein, the term “M2M/IoT server” refers to an infrastructure node thatoffers M2M services to M2M/IoT devices. These services reduce the burdenon M2M/IoT applications, and include things like: discovery, accesscontrol, connectivity. A oneM2M IN-CSE, for example, is an M2M/IoTServer that follows the oneM2M standard. 3GPP refers to such an entityas a Service Capability Server (SCS) or an Application Function (AF)

Herein, the term “PLMN transfer” refers to a transfer which involves acellular device switching from one PLMN to another. A PLMN transfer mayinvolve switching one or both of the radio access network and/or thecore network.

TABLE 1 Abbreviations 5GC 5 G Core 5GS 5 G System AE Application EntityAF Application Function AS Application Server AuC Authentication CenterAMF Access and Mobility Management Function CN Core Network CSE CommonServices Entity DN Data Network DNN Data Network Name EF ExposureFunction EHPLMN Equivalent Home PLMN EPC Evolved Packet Core EPS EvolvedPacket System HPLMN Home PLMN HSS Home Subscriber Server IMSIInternational Mobile Subscriber Identity IN-AE Infrastructure Node AEIN-CSE Infrastructure Node CSE IP Internet Protocol IoT Internet ofThings LAA License Assisted Access LTE Long Term Evolution M2M Machineto Machine MME Mobility Management Entity MNC Mobile Network Code MVNOMobile Virtual Network Operator NAS Non-Access Stratum NEF NetworkExposure Function NR New Radio NSSP Network Slice Selection Policy NWDAFNetwork Data Analytics Function PCF Policy Control Function PCRF Policyand Charging Rules Function PDU Packet Data Unit PLMN Public Land MobileNetwork RAN Radio Access Network RPLMN Registered PLMN RLOS RestrictedLocal Operator Services RSS Relative Signal Strength SCEF ServiceCapability Exposure Function SCS Service Capability Server SEPP SecurityEdge Protection Proxy SSC Session and Service Continuity SSCMSP SSC ModeSelection Policy UDM Unified Data Management (UDM): UDR Unified DataRepository UE User Equipment URSP UE Route Selection Policy USIMUniversal Subscriber Identity Module VPLMN Visited PLMN

Cellular Network Entities (Network Functions)

FIG. 1 shows a number of cellular network entities and cellular networkfunctions, that are relevant to the systems, methods, and apparatusesdescribed herein. See 3GPP TS 21.905 Vocabulary for 3GPP Specifications,V 14.1.1.

Referring to FIG. 1 , a Mobility Management Entity (MME) is an entitywithin the cellular network that manages registration, mobility, and UEreachability in IDLE mode. The MME is also involved with authenticationand authorization.

An Access and Mobility Management Function (AMF) is a network functionwithin a 5G cellular network that handles registration, connection,mobility, and reachability management. The AMF is also involved withsecurity: access authentication, access authorization, and deriving theaccess network specific keys. As such, the AMF is similar infunctionality to an MME.

A Home Subscriber Server (HSS) is an entity within the cellular networkthat stores subscription information for the connecting devices. Thesubscription information includes the subscriber identity (in the formof an IMSI) and security keys used for authentication, encryption, anddata integrity. The HSS may also include other parameters associatedwith the subscription including the services that can be accessed, thequality of service they will get, the access technologies they can use,the charging model, etc. In the examples herein, it is generally assumedthat the HSS includes functionality of the Authentication Center (AuC).However, such AuC functionality may be located in a separate entity.

A Unified Data Management (UDM) is a network function within a 5Gcellular network that stores subscription information for the connectingdevice. A UDM is similar in functionality to an HSS. In some cases theoperator subscription information may be stored in a Unified DataRepository (UDR), in which case the UDM would be a form of front endthat retrieved the subscription data from the UDR.

A Service Capability Exposure Function (SCEF) is an entity within thecellular network that exposes the services and capabilities provided by3GPP network interfaces. The SCEF allows for 3rd party applications todetermine UE reachability, set up monitoring of network events, permitgroup message delivery, etc.

A Network Exposure Function (NEF) is a network function that exposesservices and capabilities provided by a 3GPP network. The NEF alsoprovides a means for 3rd parry applications to provide information tothe cellular network, such as mobility or communication patterns forexample. As such an NEF is similar in functionality to an SCEF.

A Policy and Charging Rules Function (PCRF) is an entity within thecellular network that aggregates information to and from the network,operational support systems, and other sources (such as external 3^(rd)party servers) in real time, supports the creation of rules, and maymake policy decisions based on this input. Rules are provided to thesubscribers as well as other entities within the 3GPP network whichmanage the traffic from these subscribers.

A Policy Control Function (PCF) is a network function that receivesinput from subscription information and 3^(rd) party servers, supportsunified policy framework to govern network behavior, and provides policyrules to Control Plane functions to enforce them.

A Network Data Analytic Function (NWDAF) is a network function thatenables other network functions to request and get different type ofnetwork analytic information, such as the load level information ofNetwork Slice instance, for example.

The 5G-RAN is a New Radio (NR) radio access network that connects to,e.g., a 5G core network.

The 4G-RAN is the RAN used for LTE (Long Term Evolution).

IoT Cellular Deployments

FIG. 2 depicts a typical IoT cellular deployment. The M2M/IoTApplications are applications that remotely control/monitor/configure anM2M/IoT device. This is typically done through the aid of servicesprovided by the M2M/IoT Server and through a wireless cellular network,if these devices are cellular. 3GPP typically refers to suchapplications as Application Servers (ASs). oneM2M typically refers tosuch devices as Infrastructure Application Entities (IN-AEs).

The M2M/IoT Server is a server that provides value added M2M/IoTservices to M2M/IoT applications and M2M/IoT devices. The main purposeof the M2M/IoT server is to reduce the burden on the M2M/IoTapplications and the M2M/IoT devices. The M2M/IoT server provides a hostof functions such as data storage, data advertising, access control,etc. For the most part, it acts as a middleman between the M2M/IoTapplications and the M2M/IoT devices. As a result, applications don'tcommunicate directly with the devices. Instead, the devices store theirdata in the M2M/IoT server, from which they can be later retrieved bythe M2M/IoT application. 3GPP typically refers to the M2M/IoT Server asa Service Capability Server. oneM2M typically refers to the M2M/IoTserver as Infrastructure Capability Service Entity (IN-CSE).

It will be appreciated from FIG. 2 that an M2M/IoT Server may serve manydifferent M2M/IoT applications (e.g., APP1, APP2, APP3, and APP4). TheM2M/IoT devices may be associated/attached/registered to differentnetworks, and as a result the M2M/IoT Server serving these devices willhave an interface to each of these networks (e.g. Network 1 and Network2). An M2M/IoT application may communicate to M2M/IoT devices that areassociated, attached, or registered to different networks. An M2M/IoTdevice may communicate with many different M2M/IoT applications. M2M/IoTServer is a funnel point between the M2M/IoT applications and theNetworks and M2M/IoT devices.

PLMN Selection

In 3GPP, cellular capable devices are also known as UEs, and the networkoperators are also known as Public Land Mobile Networks (PLMNs). PLMNsare typically contained within national boundaries. Typically, anoperator will have a single PLMN per country, but in some cases,operators may have multiple PLMNs within a national boundary.

UEs need to regularly perform a procedure known as PLMN selection tofind and register to the network that will provide the UE its cellularservice. PLMN Selection is defined in TS 23.122, Non-Access-Stratum(NAS) functions related to Mobile Station (MS) in idle mode, v15.2.0.The procedure is based on a set of rules defined in the UE. A UEnormally operates on its home PLMN (HPLMN) or equivalent home PLMN(EHPLMN). However, a visited PLMN (VPLMN) may be selected, for instanceif a UE loses coverage or is roaming in a foreign country. There are twomodes for PLMN selection in TS 23.122: automatic mode and manual mode.

Automatic mode utilizes a list of PLMN/access technology combinations inpriority order. The highest priority PLMN/access technology combinationwhich is available and allowable is selected.

In manual mode, the UE indicates to the user which PLMNs are available.Only when the user makes a manual selection does the UE try to obtainnormal service on the PLMN.

A UE may maintain a number of lists in its USIM. In an EHPLMN list, a UEmay store a set of PLMNs that are equivalent to the HPLMN. The EHPLMNlist may be used by operators that have more than one assigned MobileNetwork Code (MNC), for example. In a User Controlled PLMN Selector withAccess Technology list, a UE may store a list of PLMNs that have beenprovided by the user. In an Operator Controlled PLMN Selector withAccess Technology list, a UE may store a list of PLMNs that have beenprovided by the network

A UE may store a Forbidden PLMN List, e.g., a list of PLMNs which areforbidden by the network. The UE, for example, adds to such a list aftera registration attempt where the network responds with a “PLMN notallowed” message. A UE in Automatic Mode should not attempt registrationto a PLMN on this list. A PLMN is removed from the list if aregistration while in Manual Mode is successful, or if a timerassociated with the PLMN entry expires.

Once a UE has registered on a PLMN, this PLMN is referred to as theRegistered PLMN (RPLMN). In order to avoid a UE from ping-ponging fromone PLMN to another and to speed up the initial start-up time, a UE willalways try to re-register on the last or prior RPLMN.

At switch on, or recovery from lack of coverage, if the RPLMN is nolonger available and the UE is in Automatic Mode, the UE willautonomously choose the highest priority PLMN that it found during itsPLMN search. In contrast, if the RPLMN is no longer available and the UEis in Manual Mode, it will display a ranked list of the PLMNs that itfound during its PLMN search. The user is then expected to select fromone of the found PLMNs.

The operation is slightly different while roaming in a visited PLMN. Insuch a case the UE periodically attempts to obtain service on its HPLMN(or an Equivalent HPLMN or a higher priority PLMN/access technologycombinations listed in “user controlled PLMN selector” or “operatorcontrolled PLMN selector”).

Steering or Roaming

A UE may be steered to a specific PLMN using “Steering of Roaming”. Ifthe UE receives a command of type “Steering of Roaming”, it is expectedto take certain actions. First, the UE should replace the highestpriority entries in the “Operator Controlled PLMN Selector with AccessTechnology” list stored in the UE with the list provided in the receivedcommand. Second, the UE should delete the PLMNs identified by the listin the received command from the Forbidden PLMN list, if they arepresent in these lists. Third, the UE should take the new informationinto account in subsequent attempts to access a higher priority PLMN.Last, the UE should immediately attempt to obtain service on a higherpriority PLMN.

Inter-PLMN Communication (for Roaming)

5G networks allow two modes of roaming::Home Routed, as illustrated inFIG. 3 ; and Local Breakout, as illustrated in FIG. 4 . Control planecommunication between the home and visited PLMNs is through the SecurityEdge Protection Proxy (SEPP) and over the N32 interface. The SEPP is anon-transparent proxy that mainly supports message filtering andpolicing on inter-PLMN control plane interfaces. User planecommunication is through the N9 interface, which carries multiple PDUsessions from the VPLMN to the HPLMN over a UDP/IP connection.

Shared and Unlicensed Spectrum

Use of unlicensed spectrum and shared spectrum is already available forLTE devices, and a new study item was started in 5G to study 5G NRoperating in unlicensed spectrum, both licensed-assisted and standalone.

In the study item RP-172021, Study on NR-based Access to UnlicensedSpectrum, the objectives include: “Coexistence methods within NR-basedand between NR-based operation in unlicensed and LTE-based LAA and withother incumbent RATs in accordance with regulatory requirements in e.g.,5 GHz, 37 GHz, 60 GHz bands.” In particular, the study item is to usethe coexistence methods already defined for 5 GHz band in LTE-based LAAcontext as the baseline for 5 GHz operation. However, enhancements in 5GHz over these methods are in scope. As a high-level objective, NR-basedoperation in unlicensed spectrum should not impact deployed Wi-Fiservices (such as data, video, and voice services) more than anadditional Wi-Fi network on the same carrier.

NSSP and URSP

UE Route Selection Policies (URSPs) are polices that are provided by thePCF in the 5GC to the UE. These policies are used by the UE to determinehow to route outgoing traffic. Traffic can be routed to an establishedPDU Session, can be offloaded to non-3GPP access outside a PDU Session,or can trigger the establishment of a new PDU Session.

A URSP may include: an SSCMSP (SSC Mode Selection Policy) that is usedto map traffic to an SSC mode; an NSSP (Network Slice Selection Policy)that is used to map traffic to an S-NSSAI; a DNN Selection Policy thatis used to map traffic to a DN; and access network preferences which areused to map traffic to an access network type. A UE may also have localpreferences that can be used to determine how to treat traffic. Localpreferences take precedence over URSPs.

Congestion Use Case Example

FIG. 5 is a block diagram of an example congestion use case. In FIG. 5 ,an M2M/IoT server interfaces to three operator networks (Operator 1,Operator 2, and Operator 3) through their respective Exposure Function(EF). A fleet management company (TrackUS) has a number of sensorsinstalled in all of its trucks. The vast majority of these devicesgenerate very little data and are of low priority, however a few arevideo cameras, which are turned on regularly for safety or monitoringreasons. TrackUS needed complete national coverage and so it negotiatedpreferred rates with two national operators (namely Operator 1 andOperator 3). Both rates are very good, but the rate from Operator 1 isslightly better. As a result, TrackUS would prefer that itsdevices/sensors connect to Operator 1.

Due to a traffic jam, Operator 1 experiences some heavy congestion onits signaling channel in a particular cell. In a 4G network, the EPC maysolve this problem in a “brute force” manner and bar select devices fromaccessing the network. However, rather than blocking the low-prioritysensor devices, Operator 1 decides to transfer some of these devices toanother operator. Operator 1 asks the M2M/IoT server to assist in thetransfer, as the M2M/IoT server has valuable UE context information (forinstance the preferred operators), and is in a better position todetermine which of the sensors to transfer to the other operators.

M2M/IoT server finds that operator 2 and 3 provide the necessaryservices. Operator 3 is a preferred operator, and is willing to acceptthe devices. M2M/IoT server informs the low priority sensor devices toconnect to this operator. The sensors disconnect from Operator 1, andreconnect to Operator 3 to obtain service.

Example Problems Raised by Conventional Solutions

Existing standards provide for transferring UEs between PLMNs is allowedunder two conditions. The first is during international roaming, e.g.,where the HPLMN provides no service. In such a case, the UE isregistered to a VPLMN and the HPLMN does not provide service in thecountry where the UE is roaming. In IDLE mode, the UE will periodicallytry to register to a higher priority PLMN;

The second is during national roaming, where there are coverage holes inan operator's coverage. The HPLMN and VPLMN are in the same nationalboundary, but the UE may be in a location where the reception from theHPLMN is very poor or non-existent. For example, this is known asextended coverage or extended national roaming in Canada. UEs fromOperator1 can be pushed to a competitor's network (Operator2), ifOperator1 provides no coverage to those UEs. There are no additionalroaming charges to the subscribers, and the subscriber is entitled toalmost the same set of services in the competitor's network

For the most part, PLMNs manage their own network, and they share UEsamongst each other only for coverage reasons (either due to poor signalquality in a national roaming case or lack of presence in aninternational roaming case). There is no conventional mechanism to shareUEs amongst PLMNs for non-coverage reasons, e.g., to resolve congestionor for some other optimization. As a result, the PLMN may be required tostop providing services to some UEs, e.g., by disconnecting these orrefusing registration requests. In addition, even if this transferbetween PLMNs were allowed, the PLMN may not be in the best position toselect which UEs to transfer. The unique position of the SCS in the IoTcommunication path is not fully leveraged.

The SCS has, or is able to obtain knowledge of network context andvisibility that spans multiple PLMNs (information that one PLMN wouldnot necessarily know about a neighbor PLMN), including: sliceinformation (number of slices, types of slices); load on network ornetwork slice (user plane and control plane); coverage area (or coverageholes) of network; number of UEs; number of active (CONNECTED, IDLE, orSUSPENDed) UEs in a network or network slice; and average UE latency(for mobile originated or mobile terminated traffic)

The SCS has, or is able to obtain: a great deal of UE contextinformation, such as: anything from the UE subscription; the number offlows per UE; location of the UE; mobility pattern of the UE;reachability of the UE; historical flow to/from UE; power saving stateof the UE; and transmission characteristics to/from a UE (communicationpatterns).

For purposes of illustration, solutions are presented herein as a meansto share UEs amongst PLMNs for non-coverage reasons, e.g., to resolvecongestion or for some other optimization. However, the same solutionsmay also be used for sharing UEs amongst PLMNs for coverage reasons. Forexample, a UE may be transferred to a Mobile Virtual Network Operator(MVNO) using any of the techniques described herein.

PLMN Transfer

The call flows of FIGS. 6-14 show example methods of achieving PLMNtransfer. For simplicity, in FIGS. 6-14 , it is assumed that the UE isinitially connected to its Home PLMN and that it is then transferred toa VPLMN. It should be understood that the solutions may also apply tothe case that a UE is connected to a visited PLMN and that it istransferred to another VPLMN or the HPLMN. For example, a UE isconnected to VPLMN1 and VPLMN1 becomes congested. In this case, VPLMN1may ask the server to transfer some UEs. The server could then determinethat it may transfer the UEs to another VPLMN (VPLMN2) or bring themback to the HPLMN.

In each of the methods of FIGS. 6-14 , whenever new PLMN selectionpolicies are provided to the UE, new NSSP of the URSP rules may also beprovided.

PLMN Reselection Triggered by M2M/IoT Device

Manual Network Selection may be achieved by the device owner through theM2M/IoT server. The M2M/IoT device provides a list of PLMN/RATcombinations to the M2M/IoT server, which then selects the combinationto try.

It is assumed that some PLMNs will permit M2M/IoT devices to connectwith very limited and restricted access, for example via a RestrictedLocal Operator Services (RLOS) connection. This access allows thesedevices to contact their M2M/IoT server and have the server assist inPLMN selection. These PLMNs may broadcast an indication that theysupport “Restricted Access for Network Selection Assistance” or they maybroadcast that they support RLOS and the UE may use the RLOS connectionto determine that the network supports “Restricted Access for NetworkSelection Assistance” and then use the RLOS connection to begin“Restricted Access for Network Selection Assistance”. The details areshown in FIGS. 6 and 7 and are described below.

In the examples of FIGS. 6 and 7 , it is assumed that the M2M/IoT deviceDev1 is deployed, and that the M2M/IoT application has informed theM2M/IoT server that the specific M2M/IoT device (Dev1) has a preferredPLMN/RAT list. For example, the list may include the followingcombinations from 3 PLMNs and 2 RAT types: PLMN1/RAT1; PLMN1/RAT2;PLMN2/RAT1; PLMN3/RAT1; and PLMN2/RAT1.

In step 0, the PLMN of core network 1 broadcasts that it supports“Restricted Access for Network Selection Assistance” as part of itssystem information.

In step 1, DEV1 performs a PLMN search (either as a result of power on,loss of connectivity, or a periodic search) and determines a candidatePLMN/RAT list. For each entry in this list, DEV1 also determines thestrength of the strongest cell (for example the relative signal strength(RSS)). DEV1 does not see the prior Registered PLMN in this list. It hasno policy on which PLMN to select, or if such a policy exists, it isdisabled. For example, a 3GPP UE may be set to Manual Network Selectionmode.

As part of the search, DEV1 may determine if a PLMN allows “RestrictedAccess for Network Selection Assistance.”

In step 2, DEV1 registers with a core network. DEV1 may choose from thefound PLMN/RAT combinations that supports “Restricted Access for NetworkSelection Assistance”. For example, DEV1 may select randomly from one ofthe found PLMN/RAT combinations, it may choose the combination with thestrongest signal, it may choose a PLMN/RAT combination that it usedpreviously, or it may choose the first found PLMN/RAT combination. Forpurposes of the example of FIGS. 6 and 7 , it is assumed that theM2M/IoT device selects Core Network 1. The Registration Request mayinclude Registration Type=Restricted Access for Network SelectionAssistance, for example, as an indication to the core network that theregistration request is for limited access to allow device to contactthe M2M/IoT server.

In step 3, Core Network 1 accepts the registration.

In step 4, DEV1 issues a new NAS control message ManualNetworkSelectionRequest to core Network 1. For example, this message may be directed tothe AMF of core network 1. The request may include a PLMN/RAT list, suchas a list of discovered cells. Each entry in the list may include thereceived signal strength of the strongest cell and the identity of thestrongest cell (for example a cell ID). Alternatively, the list may beordered from strongest to weakest PLMN/RAT combination. The request mayalso include an address of the device's M2M/IoT server.

In step 5, the AMF of Core Network 1 forwards the request to the NEF,which in turn, forwards the request to the M2M/IoT server. The corenetwork may include other UE context information in the request, such asthe location of DEV1 (for example, the cell identity or the trackingarea identity) or the network slice being used.

The call flow of FIG. 6 continues in FIG. 7 . In step 6 of FIG. 7 , theM2M/IoT server selects the PLMN/RAT combination using the storedpreferred PLMN/RAT list and other received UE context informationreceived in the request. The server may have a local policy to assist inselecting the PLMN/RAT combination. The server may display the receivedinformation on a graphical user interface to allow a user to select thePLMN/RAT combination. The server may send a notification to a configuredthird party application server to have it select the PLMN/RATcombination.

Once the PLMN/RAT selection is made, the M2M/IoT server sends aManualNetworkSelection Response back to the NEF of core network 1, whichsends it to the AMF and further to the M2M/IoT device.

In step 7, the M2M/IoT device de-registers with Core Network 1, andregisters with Core Network 2.

As an alternative to step 4 of FIG. 6 , the UE may establish a PDUsession in the core network, and use IP to send theManualNetworkSelection Request to the M2M/IoT server. For example, anRLOS connection may be used to reach the IoT Server.

As another alternative to step 4 of FIG. 6 , the message may beforwarded from the AMF to the PCF. The PCF may generate a new preferredPLMN/RAT list and send it to the UE. The PCF may involve the IoT Serverin this process by querying the IoT Server (via the NEF) to obtain itsPLMN preferences.

As another alternative, the information in Step 4 of FIG. 6 may be sentwith the initial registration request (Step 2). For example, theManualNetworkSelection Request, may be embedded inside the RegistrationRequest. Subsequently, Core Network 1 may extract theManualNetworkSelection Request and forward it to the M2M/IoT Server forassistance. The ManualPLMNSelection Response may then be included insidea Registration Reject message from Core Network 1. The UE may thenextract the PLMN information from then ManualPLMNSelection response, andattempt a subsequent registration to this PLMN.

PLMN Reselection Triggered by Core Network

When the core network detects conditions that can be resolved bytransferring some UEs to another PLMN, the core network may ask theM2M/IoT server for assistance.

It is assumed that the M2M/IoT server has a preference of PLMNs, andwould like to control aspects of transferring devices to another PLMN.The details are shown in FIGS. 8-10 , and described below.

In step 1 of FIG. 8 , an M2M/IoT device (DEV1) registers with corenetwork 1. As part of the registration, the UE includes its capability,where DEV1 indicates that it is capable of core network directed PLMNreselection. Alternatively, this information may be part of the devicessubscription information. The Registration Accept message may indicateto the UE if the network supports this capability, or the indication mayhave been broadcast by the network.

In step 2, Core Network 1 determines to start monitoring for problemconditions. AMF1 issues a MonitorSubscribe Request to the NWDAF1associated with core network 1. The NWDAF provides advanced analyticaldata about core network 1. For example, AMF1 may subscribe to monitor:user plane UL and/or DL loads in RAN; user plane UL and/or DL loads incore network; control plane UL and/or DL loads in RAN; control plane ULand/or DL loads in core network; or buffering load in the core network,e.g., for UEs that are not reachable.

In addition, the granularity of the subscribe request may be targeting aspecific cell, tracking area, network slice, UE, or group of UEs. Therequest may be for a periodic update or based on the monitored criteriacrossing thresholds

For the call flow, it is assumed that AMF1 has requested to be notifiedwhen the buffering, device count, control plane connection, or userplane connection load in the core network exceeds a threshold (forinstance 70% of maximum capacity).

In step 3, at some point the buffering load exceeds the threshold. TheNWDAF1 sends a MonitorNotify Request to the AMF. This may include a listof UEs that are contributing to the buffer overflow.

In step 4, AMF1 determines that the majority of the offending UEs areusing the services of the M2M/IoT Server. AMF1 may decide to initiatethe procedure to offload a number of UEs to another PLMN. Alternatively,the AMF and/or the NWDAF may provide the necessary information to thePCF (offending UEs, M2M/IoT servers servicing these UEs, load on thenetwork, location of the offending UEs etc.) and the PCF may use somelocal policy to determine if the network should initiate offload of someUEs to another PLMN.

The call flow of FIG. 8 continues in FIG. 9 . In step 5 of FIG. 9 , AMF1sends a UETransferInd Request to the M2M/IoT Server. The request maycontain UE context information, including a list of UEs for potentialtransfer, or a request to transfer a percentage of UEs. This request issent via NEF1 to the M2M/IoT Server. This request may include anindication of the location of the UEs, the observed traffic loads (userplane and control plane), the reachability cycle of the UE, the networkslice type of the UE, etc. This request may also include an indicationof the reason for the transfer (for example, S-GW DL buffer load, ULsignaling load, etc.). This request may be sent to the PCF rather thanthe M2M/IoT Server. The PCF may then decide what devices should beoffloaded.

In step 6, the M2M/IoT server (or PCF1), determines the UEs that itshould transfer. The call flow assumes that DEV1 is one of these UEs.The M2M/IoT server determines the offload PLMN for DEV1. For example, itmay know that core network 2 is a preferred PLMN for this UE, or it maymake its decision based on the UE context information in the request.For example, the M2M/IoT server may have coverage maps of all the PLMNs,and may determine which PLMNs provide service at the UEs currentlocation and are suitable candidates for offload PLMN. If necessary, thePCF1 may obtain this information from the M2M/IoT Server.

In step 7, the M2M/IoT server (or PCF1) asks Core network 2 if it iswilling to accept DEV1 (using UETransfer Request). As part of thisrequest, the M2M/IoT server (or PCF1) may include any UE context that ithas available (communication patterns, observed traffic loads,reachability cycle, location of UE, etc.) The message is sent to AMF2,through NEF2 (or to PCF2). If necessary, PCF1 may communicate to CoreNetwork 2 either directly, via the SEPP, via the NEF, or through theM2M/IoT Server.

In step 8, AMF2 (or PCF2) decides whether it is willing to accept theregistration of DEV1. If yes, it may issue a UETransfer Response back tothe M2M/IoT server. This may include an indication of a time window toexecute this registration. The time window may be used to spread out theregistration requests from UEs that are transferred to core network 2.If the time window expires, core network 2 may assume that the UE willnot be transferred to core network 2.

Core Network 2 may decide that is not willing to accept the registrationof DEV1. This may be because of its own load concerns, or because it hasno or little coverage at the location of the UE.

In step 9 of FIG. 10 , the M2M/IoT server (or PCF2) responds back tocore network 1, with an indication of the UEs that will be transferred,and the new PLMN for these UEs. This information is included in theUETransferInd Response message.

The call flow of FIG. 9 continues in FIG. 10 . In step 10 of FIG. 10 ,AMF1 sends a PLMNUpdate Request to DEV1 with the new PLMN information.This can be through a periodic registration procedure, tracking areaupdate procedure, or through a new dedicated control plane procedure.Alternatively, AMF1 may send an SMS to DEV1 with a USAT REFRESH commandqualifier of type “Steering of Roaming”, effectively steering DEV1 tothe selected PLMN (core network 2).

The request may also include an activation time, to inform the UE whenit should attempt a registration on core network 2. If a large number ofUEs are transferred to core network 2, this may be used to reduce thesignaling load on core network 2, as the activation time may be used tospread out the registration requests to core network 2.

In step 11, DEV1 de-registers from core network 1, and registers withcore network 2 at the appropriate time.

As an alternative to Step 10 and Step 11, the PLMNUpdate request mayinclude a time window over which to perform the initial registration oncore network 2. DEV1 can then randomly choose a time in this window, toattempt its initial registration.

In order to assist the M2M/IoT server and provide additional UE contextinformation, in Step 4 the AMF1 may ask the UE to report neighbor PLMNinformation. The UE may then perform a PLMN search, and provide thefound PLMN/RAT combinations to core network 1, along with an indicationof the received signal strength for the PLMN/RAT combination.Alternatively, the UE could be configured to periodically measure thesignal strength of neighbor PLMNs, and report the signal information tocore network1. This neighbor PLMN information may be included as part ofthe UE context information provided to the M2M/IoT server in Step 5.

PLMN Reselection Triggered by M2M/IoT Server

The M2M/IoT server may gather information and detect conditions that maybe beneficially addressed by transferring some UEs from one PLMN toanother PLMN.

Owing to the location of the M2M/IoT server in the communication pathbetween the core networks and M2M/IoT applications, the M2M/IoT serveris in a unique position to collect context information from both andmake determinations of the optimum PLMN to serve a device. The detailsare shown in FIGS. 11-14 and described below.

In step 1 of FIG. 11 is identical to step 1 of FIG. 8 .

In step 2 a/2 b, the M2M/IoT server collects context information fromthe core networks. For example, this may include load information, e.g.,per cell, tracking area, network slice, UE, and group of UEs. Theinformation may include network capacity information, such as historicalnetwork usage for different periods, e.g., per hour, per day, per week,per holiday, etc. Similarly, the information may include UEs that arepart of a multicast group and UEs that are using unlicensed or sharedspectrum, as well as the type of spectrum.

The M2M/IoT server may subscribe to have this information providedperiodically and/or upon change. The subscriptions may be configured onthe NWDAF, PCF, AMF, or UDM/UDR via the NEF.

In steps 3 a and 3 b, the M2M/IoT Server collects information from theM2M/IoT applications. For example, the server may collect the overalldemand from each M2M/IoT application, e.g., in the form of communicationpatterns for different periods.

In step 4, the M2M/IoT server uses the context information and networkstatus information to determine if certain devices may need to betransferred from one PLMN to another. For example, the M2M/IoT servermay determine to transfer UEs for purposes of load balancing, sharingmulticast groups, minimizing interference on shared spectrum, oroptimizing resource and service allocation, for example.

For load balancing, for example, the M2M/IoT server can aggregate thedemands of all the M2M/IoT applications and determine the overall demandfor each UE. It also knows the available capacity of each of the corenetworks. M2M/IoT server may dynamically match the demand to theavailable capacity in order spread the load of these UEs across all thecore networks. For example, it may determine that DEV1 should be on corenetwork 1 from 8 AM to 3 PM, and on core network 2 otherwise.

For sharing multicast groups, the M2M/IoT server may know that it has amulticast message to send to a group of UEs. Part of this group of UEsis registered with core network 1 (SubGroup1), while the remainder ofthe group is registered with core network 2 (SubGroup2). Rather thanusing a separate multicast group in each core network, the M2M/IoTserver would like to create a single multicast group in only onenetwork. As a result, it transfers all the UEs from one subgroup to theother core network. For example, the M2M/IoT server may determine thatit needs to regularly send a multicast message to DEV1, and 20 otherdevices. The 20 other devices are registered to core network 2 and arepart or multicast group in that network. To take advantage of thisexisting group, and avoid sending the multicast message to 2 differentcore networks, the M2M/IoT server may ask DEV1 to register to corenetwork 2.

For minimizing interference on shared spectrum, the M2M/IoT server maydetermine that it communicates to two sets of UEs that are using thesame shared spectrum. Set 1 UEs are registered to Core Network 1 whileSet 2 UEs are registered to Core Network 2. The M2M/IoT server may alsoknow that these devices are in vicinity of each other. As each of thetwo networks manages their shared spectrum individually, the UEsregistered in the 2 networks compete against each other. Moving the 2sets of UEs to a single core network allows the core network to bettercoordinate traffic to and from these UEs and minimize interference.

For optimizing resource and service allocation, the M2M/IoT server maydetermine that one or more UEs do not need full network services for aspecific duration. In this case the M2M/IoT server may request thetransfer of these UEs to a PLMN which supports “Restricted Access forNetwork Selection Assistance” on purpose, and for a specific duration.This is followed later by PLMN re-selection to a PLMN where the UE mayreceive full network services.

The call flow of FIG. 11 continues in FIG. 12 .

In step 5, of FIG. 12 , once the M2M/IoT server has determined that itwould prefer to transfer DEV1 from core network 1 to core network 2, itmay need to retrieve other UE context information for Dev1. For example,it may need to verify that DEV1 is capable of PLMN transfers.

Steps 6-10 of FIGS. 12, 13, and 14 are similar to steps 7-11 of FIGS. 9and 10 .

Proactive PLMN Selection Lists

The M2M/IoT server is also capable of determining a set of PLMN listsand supplying this set to the UE. The UE may then use a local policy todetermine which PLMN list to use. The policy may be based on one or moreof the following: UE location, UE load, applications running on UE, etc.

The M2M/IoT server may collect information from the PLMNs (coveragemaps, load, etc.) and the Application servers (served UEs, UEtrajectory, etc.) and from this determine one or more PLMN Selectionlists. These selection lists may then be transferred to the UE throughNAS signaling or through some USAT command targeting the USIM within theUE. The UE may then regularly use its local policy to select among thePLMN selection list and perform a PLMN selection/reselection.

For example, based on the information collected from the core networksand the application servers, the M2M/IoT server may generate a number ofPLMN selection lists, which are based on the UE's current location andcurrent active applications. For example, the server may create thefollowing five lists:

-   -   PLMN List 1: Location: City A, UE applications: any    -   PLMN List 2: Location: City B, UE applications: any    -   PLMN List 3: Location: elsewhere, UE applications: Application 1    -   PLMN List 4: Location: elsewhere, UE applications: Application 2    -   PLMN List 5: default

The M2M/IoT server may then send these lists to the UE, for examplethrough a USAT command or through the core network to which the UE iscurrently registered.

The UE updates its lists, and uses its local policy to determine whichlist to use. If no valid condition matching a list is found, the UE mayuse the default PLMN List 5.

Non-Roaming—Visited Routing

An M2M/IoT device with limited radio access capabilities, may not beable to be transferred to another PLMN. In such cases an alternativeroaming scheme called Non-Roaming—Visited Routing may be used.

In the discussions of FIGS. 6-14 , it has been assumed that the M2M/IoTdevice is either registered to its Home PLMN or is transferred toanother PLMN, e.g., a visiting PLMN. As far as the network is concerned,when a UE is transferred from its home PLMN to a visiting PLMN, it iseffectively roaming. 3GPP defines two variants of roaming: localbreakout and Home routed. Both variants refer to the user plane path. Inthe local breakout case, the user plane path stays in the visited PLMNand the VPLMN routes the data to the data network. In the home routedcase, the user plane path returns to the home PLMN, and the HPLMN routesthe data to the data network. These three alternatives—non-roaming,local breakout roaming, and home routed roaming—are illustrated inconfigurations a, b, and c, respectively, in FIG. 15 .

FIG. 15 shows a total of six functional entities in five configurations.The first entity is the UE, which is the device requiring service from awireless operator. The UE connects to a RAN entity based on its radioaccess capability. The second entity is the RAN h, which is a radioaccess network functional entity of the Home PLMN. The RAN h correspondsto a specific technology and frequency band.

The third entity is the RAN_v, which is a radio access networkfunctional entity of a Visited PLMN. The RAN_v corresponds to a specifictechnology and frequency band. The entity fourth is the CN_h, which isthe core network functional entity of the Home PLMN. It corresponds to aspecific type (e.g. EPC, 5GS) and a specific capability (e.g. slicessupported, services supported).

The fifth entity is the CN_v, which is the core network functionalentity of the Visited PLMN. It corresponds to a specific type (e.g. EPC,5GS) and a specific capability, e.g., slices supported and servicessupported. The sixth entity is the DN, which is the data network withwhich the UE wishes to communicate.

For simplicity, FIG. 15 omits the inner network functions of the corenetwork.

For M2M/IoT devices a fourth roaming alternative is possible. In somecases, an M2M/IoT device will only support a single RAT and only theband of its preferred operator. These devices will only be able toconnect to the RAN of the HPLMN.

Similarly, in some cases an operator may not want to instantiate adedicated network slice for only a few M2M/IoT devices. Rather it maywant to leverage its relationship with another operator which doesprovide the dedicated network slice. It may want to push these devicesto this other operator.

However, owing to their RAT limitations, these M2M/IoT devices will notbe able to connect to the RAN of the other operator as the device doesnot support the RAN and/or band. For such devices, another roamingalternative is proposed, referred to as Non-Roaming Visited Routing(shown as “d” in FIG. 15 .) In this alternative, the UE connects to theRAN h (the RAN of the Home PLMN). The control plane and user planetraffic are then routed to the visited PLMN (CN_v) which offers theadvanced services needed by the UEs. This saves the home PLMN fromoffering these services.

Note that the functionality within CN_h can be variable. For instance itmay have minimal functionality just to support the inter-PLMNcommunication. It may provide part of the control plane functionality,or it may provide the full user plane functionality. Similarly, it mayprovide access to the data network through its NEF, e.g., with a UPF inthe CN_v sending/receiving user plane traffic to/from the NEF of CN_h.

As the latter two cases above rely on the HPLMN for routing the trafficto the DN, they are classified as “Non-Roaming—Partial Visited Routing”,in order to distinguish them from the other cases. The alternative isshown in e) of FIG. 15 .

This roaming alternative may be used in any of the PLMN transfersdescribed in connection with FIGS. 6-14 . To support such transfers, itis proposed that the entity triggering the transfer may specify whattype of transfer it is requesting (roaming—local breakout, roaming—homerouted, non-roaming—visited routing). The specific details are shown inFIGS. 16-18 for the core network triggered PLMN Reselection. Note thatfor legibility and simplicity, the call flows of FIGS. 6-18 are eachsplit across several pages of figures. Further, entities participatingin the call flow may be omitted on individual pages of drawings to avoidclutter.

Steps 1-6 of FIGS. 16 and 17 are analogous to steps 1-6 of FIGS. 8 and 9.

In step 7 of FIG. 17 , once the M2M/IoT server has determined the UEs totransfer, it may need additional UE information from core network 1,such as the UE radio access capability, for example.

The call flow of FIGS. 16 and 17 continues in FIG. 18 . In step 8 ofFIG. 18 , the M2M/IoT server asks Core network 2 it is willing to acceptDEV1, e.g., using a UETransfer Request. As part of this request, theM2M/IoT server may include any UE context that it has available(communication patterns, observed traffic loads, reachability cycle, UEradio access capability, the type of transfer (roaming—local breakout,roaming—home routed, non-roaming—visited routing), etc.). The message issent to AMF2 (or PCF2), through NEF2.

In step 9, AMF2 (or PCF2) decides whether it is willing to accept theregistration of DEV1. If yes, it issues a UETransfer Response back tothe M2M/IoT server. This may include an indication of a time window toexecute this registration. It may also indicate that the UE can only beserved using non-roaming—visited routing.

In step 10, the M2M/IoT server responds back to core network 1, with anindication of the UEs that will be transferred, the new PLMN for theseUEs, and the roaming alternative to use for these UEs. This informationis included in the UETransferInd Response message.

In step 11, if DEV1 has been selected to use a non-roaming—visitedrouting alternative, AMF1 will set up the inter-PLMN communicationbetween the two PLMNs, e.g., as may be done for the roamingalternatives.

The UE is unaware of this PLMN change, and it continues to use the sameRAN. Once the RAN node forwards the user plane and control plane trafficto core network 1, it is the responsibility of core network 1 to routethis traffic to core network 2

As an alternative, RAN h may have a connection to both CN_h and CN_v,e.g., in a shared network configuration. RANs in the HPLMN may broadcastthat they are shared cells, e.g., shared between CN_h and CN_v. From thebroadcast information, the UE may know the core networks availablethrough the cell, as well as the capabilities of each of these cells,e.g., in terms of network slices supported. In this alternative, Step 11of FIG. 18 would be replaced by an AMF change procedure, where the AMFserving the UE is changed from AMF1 to AMF2.

Graphical User Interface

FIG. 19 shows an example deployment with the three Graphical UserInterfaces (GUIs). A (GUI) may be implemented within the core network,at the M2M/IoT Server, or at the M2M/IoT device, for example. Theinterface may be used to trigger certain actions described in thisdocument as well as view status related to the PLMN transfer operation.

A GUI may be used at the UE to view the type of access of a UE (e.g.,restricted access for network selection assistance, RLOS, normal), or totrigger a server assisted network selection, for example.

A GUI may be used in the Core Network to configure or view PLMNselection policies for non-coverage related PLMN transfers, for example.For instance, to configure a policy where a UE is transfer if thebuffering load in the core network exceeds 70% of maximum, and thenumber of registered UEs is above 1000.

A GUI may be used in the M2M/IoT server to trigger a PLMN transfer for aUE or group of UEs, for example. This may include the target PLMN foreach UE. A GUI may be used in the M2M/IoT server to enter the preferredoperators of a UE or group of UEs.

Example Architectures

The 3rd Generation Partnership Project (3GPP) develops technicalstandards for cellular telecommunications network technologies,including radio access, the core transport network, and servicecapabilities—including work on codecs, security, and quality of service.Recent radio access technology (RAT) standards include WCDMA (commonlyreferred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards,and New Radio (NR), which is also referred to as “5G”. 3GPP NR standardsdevelopment is expected to continue and include the definition of nextgeneration radio access technology (new RAT), which is expected toinclude the provision of new flexible radio access below 7 GHz, and theprovision of new ultra-mobile broadband radio access above 7 GHz. Theflexible radio access is expected to consist of a new, non-backwardscompatible radio access in new spectrum below 7 GHz, and it is expectedto include different operating modes that may be multiplexed together inthe same spectrum to address a broad set of 3GPP NR use cases withdiverging requirements. The ultra-mobile broadband is expected toinclude cmWave and mmWave spectrum that will provide the opportunity forultra-mobile broadband access for, e.g., indoor applications andhotspots. In particular, the ultra-mobile broadband is expected to sharea common design framework with the flexible radio access below 7 GHz,with cmWave and mmWave specific design optimizations.

3GPP has identified a variety of use cases that NR is expected tosupport, resulting in a wide variety of user experience requirements fordata rate, latency, and mobility. The use cases include the followinggeneral categories: enhanced mobile broadband (eMBB) ultra-reliablelow-latency Communication (URLLC), massive machine type communications(mMTC), network operation (e.g., network slicing, routing, migration andinterworking, energy savings), and enhanced vehicle-to-everything (eV2X)communications, which may include any of Vehicle-to-VehicleCommunication (V2V), Vehicle-to-Infrastructure Communication (V2I),Vehicle-to-Network Communication (V2N), Vehicle-to-PedestrianCommunication (V2P), and vehicle communications with other entities.Specific service and applications in these categories include, e.g.,monitoring and sensor networks, device remote controlling,bi-directional remote controlling, personal cloud computing, videostreaming, wireless cloud-based office, first responder connectivity,automotive ecall, disaster alerts, real-time gaming, multi-person videocalls, autonomous driving, augmented reality, tactile internet, virtualreality, home automation, robotics, and aerial drones to name a few. Allof these use cases and others are contemplated herein.

FIG. 20 illustrates an example communications system 100 in which thesystems, methods, and apparatuses described and claimed herein may beused. The communications system 100 may include wirelesstransmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, 102 e, 102 f,and/or 102 g, which generally or collectively may be referred to as WTRU102 or WTRUs 102. The communications system 100 may include, a radioaccess network (RAN) 103/104/105/103 b/104 b/105 b, a core network106/107/109, a public switched telephone network (PSTN) 108, theInternet 110, other networks 112, and Network Services 113. 113. NetworkServices 113 may include, for example, a V2X server, V2X functions, aProSe server, ProSe functions, IoT services, video streaming, and/oredge computing, etc.

It will be appreciated that the concepts disclosed herein may be usedwith any number of WTRUs, base stations, networks, and/or networkelements. Each of the WTRUs 102 may be any type of apparatus or deviceconfigured to operate and/or communicate in a wireless environment. Inthe example of FIG. 20 , each of the WTRUs 102 is depicted in FIGS.20-24 as a hand-held wireless communications apparatus. It is understoodthat with the wide variety of use cases contemplated for wirelesscommunications, each WTRU may comprise or be included in any type ofapparatus or device configured to transmit and/or receive wirelesssignals, including, by way of example only, user equipment (UE), amobile station, a fixed or mobile subscriber unit, a pager, a cellulartelephone, a personal digital assistant (PDA), a smartphone, a laptop, atablet, a netbook, a notebook computer, a personal computer, a wirelesssensor, consumer electronics, a wearable device such as a smart watch orsmart clothing, a medical or eHealth device, a robot, industrialequipment, a drone, a vehicle such as a car, bus or truck, a train, oran airplane, and the like.

The communications system 100 may also include a base station 114 a anda base station 114 b. In the example of FIG. 20 , each base stations 114a and 114 b is depicted as a single element. In practice, the basestations 114 a and 114 b may include any number of interconnected basestations and/or network elements. Base stations 114 a may be any type ofdevice configured to wirelessly interface with at least one of the WTRUs102 a, 102 b, and 102 c to facilitate access to one or morecommunication networks, such as the core network 106/107/109, theInternet 110, Network Services 113, and/or the other networks 112.Similarly, base station 114 b may be any type of device configured towiredly and/or wirelessly interface with at least one of the RemoteRadio Heads (RRHs) 118 a, 118 b, Transmission and Reception Points(TRPs) 119 a, 119 b, and/or Roadside Units (RSUs) 120 a and 120 b tofacilitate access to one or more communication networks, such as thecore network 106/107/109, the Internet 110, other networks 112, and/orNetwork Services 113. RRHs 118 a, 118 b may be any type of deviceconfigured to wirelessly interface with at least one of the WTRUs 102,e.g., WTRU 102 c, to facilitate access to one or more communicationnetworks, such as the core network 106/107/109, the Internet 110,Network Services 113, and/or other networks 112.

TRPs 119 a, 119 b may be any type of device configured to wirelesslyinterface with at least one of the WTRU 102 d, to facilitate access toone or more communication networks, such as the core network106/107/109, the Internet 110, Network Services 113, and/or othernetworks 112. RSUs 120 a and 120 b may be any type of device configuredto wirelessly interface with at least one of the WTRU 102 e or 102 f, tofacilitate access to one or more communication networks, such as thecore network 106/107/109, the Internet 110, other networks 112, and/orNetwork Services 113. By way of example, the base stations 114 a, 114 bmay be a Base Transceiver Station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite,a site controller, an access point (AP), a wireless router, and thelike.

The base station 114 a may be part of the RAN 103/104/105, which mayalso include other base stations and/or network elements (not shown),such as a Base Station Controller (BSC), a Radio Network Controller(RNC), relay nodes, etc. Similarly, the base station 114 b may be partof the RAN 103 b/104 b/105 b, which may also include other base stationsand/or network elements (not shown), such as a BSC, a RNC, relay nodes,etc. The base station 114 a may be configured to transmit and/or receivewireless signals within a particular geographic region, which may bereferred to as a cell (not shown). Similarly, the base station 114 b maybe configured to transmit and/or receive wired and/or wireless signalswithin a particular geographic region, which may be referred to as acell (not shown). The cell may further be divided into cell sectors. Forexample, the cell associated with the base station 114 a may be dividedinto three sectors. Thus, for example, the base station 114 a mayinclude three transceivers, e.g., one for each sector of the cell. Thebase station 114 a may employ Multiple-Input Multiple Output (MIMO)technology and, therefore, may utilize multiple transceivers for eachsector of the cell, for instance.

The base station 114 a may communicate with one or more of the WTRUs 102a, 102 b, 102 c, and 102 g over an air interface 115/116/117, which maybe any suitable wireless communication link (e.g., Radio Frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, cmWave,mmWave, etc.). The air interface 115/116/117 may be established usingany suitable Radio Access Technology (RAT).

The base station 114 b may communicate with one or more of the RRHs 118a and 118 b, TRPs 119 a and 119 b, and/or RSUs 120 a and 120 b, over awired or air interface 115 b/116 b/117 b, which may be any suitablewired (e.g., cable, optical fiber, etc.) or wireless communication link(e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). Theair interface 115 b/116 b/117 b may be established using any suitableRAT.

The RRHs 118 a, 118 b, TRPs 119 a, 119 b and/or RSUs 120 a, 120 b, maycommunicate with one or more of the WTRUs 102 c, 102 d, 102 e, 102 fover an air interface 115 c/116 c/117 c, which may be any suitablewireless communication link (e.g., RF, microwave, IR, ultraviolet UV,visible light, cmWave, mmWave, etc.) The air interface 115 c/116 c/117 cmay be established using any suitable RAT.

The WTRUs 102 may communicate with one another over a direct airinterface 115 d/116 d/117 d, such as Sidelink communication which may beany suitable wireless communication link (e.g., RF, microwave, IR,ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface115 d/116 d/117 d may be established using any suitable RAT.

The communications system 100 may be a multiple access system and mayemploy one or more channel access schemes, such as CDMA, TDMA, FDMA,OFDMA, SC-FDMA, and the like. For example, the base station 114 a in theRAN 103/104/105 and the WTRUs 102 a, 102 b, 102 c, or RRHs 118 a, 118 b,TRPs 119 a, 119 b and/or RSUs 120 a and 120 b in the RAN 103 b/104 b/105b and the WTRUs 102 c, 102 d, 102 e, and 102 f, may implement a radiotechnology such as Universal Mobile Telecommunications System (UMTS)Terrestrial Radio Access (UTRA), which may establish the air interface115/116/117 and/or 115 c/116 c/117 c respectively using Wideband CDMA(WCDMA). WCDMA may include communication protocols such as High-SpeedPacket Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may includeHigh-Speed Downlink Packet Access (HSDPA) and/or High-Speed UplinkPacket Access (HSUPA).

The base station 114 a in the RAN 103/104/105 and the WTRUs 102 a, 102b, 102 c, and 102 g, or RRHs 118 a and 118 b, TRPs 119 a and 119 b,and/or RSUs 120 a and 120 b in the RAN 103 b/104 b/105 b and the WTRUs102 c, 102 d, may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface115/116/117 or 115 c/116 c/117 c respectively using Long Term Evolution(LTE) and/or LTE-Advanced (LTE-A), for example. The air interface115/116/117 or 115 c/116 c/117 c may implement 3GPP NR technology. TheLTE and LTE-A technology may include LTE D2D and/or V2X technologies andinterfaces (such as Sidelink communications, etc.) Similarly, the 3GPPNR technology may include NR V2X technologies and interfaces (such asSidelink communications, etc.)

The base station 114 a in the RAN 103/104/105 and the WTRUs 102 a, 102b, 102 c, and 102 g or RRHs 118 a and 118 b, TRPs 119 a and 119 b,and/or RSUs 120 a and 120 b in the RAN 103 b/104 b/105 b and the WTRUs102 c, 102 d, 102 e, and 102 f may implement radio technologies such asIEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access(WiMAX)), CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000(IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856),Global System for Mobile communications (GSM), Enhanced Data rates forGSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114 c in FIG. 20 may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a train, an aerial, a satellite,a manufactory, a campus, and the like. The base station 114 c and theWTRUs 102, e.g., WTRU 102 e, may implement a radio technology such asIEEE 802.11 to establish a Wireless Local Area Network (WLAN).Similarly, the base station 114 c and the WTRUs 102, e.g., WTRU 102 d,may implement a radio technology such as IEEE 802.15 to establish awireless personal area network (WPAN). The base station 114 c and theWTRUs 102, e.g., WRTU 102 e, may utilize a cellular-based RAT (e.g.,WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell orfemtocell. As shown in FIG. 20 , the base station 114 c may have adirect connection to the Internet 110. Thus, the base station 114 c maynot be required to access the Internet 110 via the core network106/107/109.

The RAN 103/104/105 and/or RAN 103 b/104 b/105 b may be in communicationwith the core network 106/107/109, which may be any type of networkconfigured to provide voice, data, messaging, authorization andauthentication, applications, and/or Voice Over Internet Protocol (VoIP)services to one or more of the WTRUs 102. For example, the core network106/107/109 may provide call control, billing services, mobilelocation-based services, pre-paid calling, Internet connectivity, packetdata network connectivity, Ethernet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication.

Although not shown in FIG. 20 , it will be appreciated that the RAN103/104/105 and/or RAN 103 b/104 b/105 b and/or the core network106/107/109 may be in direct or indirect communication with other RANsthat employ the same RAT as the RAN 103/104/105 and/or RAN 103 b/104b/105 b or a different RAT. For example, in addition to being connectedto the RAN 103/104/105 and/or RAN 103 b/104 b/105 b, which may beutilizing an E-UTRA radio technology, the core network 106/107/109 mayalso be in communication with another RAN (not shown) employing a GSM orNR radio technology.

The core network 106/107/109 may also serve as a gateway for the WTRUs102 to access the PSTN 108, the Internet 110, and/or other networks 112.The PSTN 108 may include circuit-switched telephone networks thatprovide Plain Old Telephone Service (POTS). The Internet 110 may includea global system of interconnected computer networks and devices that usecommon communication protocols, such as the Transmission ControlProtocol (TCP), User Datagram Protocol (UDP), and the internet protocol(IP) in the TCP/IP internet protocol suite. The other networks 112 mayinclude wired or wireless communications networks owned and/or operatedby other service providers. For example, the networks 112 may includeany type of packet data network (e.g., an IEEE 802.3 Ethernet network)or another core network connected to one or more RANs, which may employthe same RAT as the RAN 103/104/105 and/or RAN 103 b/104 b/105 b or adifferent RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d, 102 e, and 102 f inthe communications system 100 may include multi-mode capabilities, e.g.,the WTRUs 102 a, 102 b, 102 c, 102 d, 102 e, and 102 f may includemultiple transceivers for communicating with different wireless networksover different wireless links. For example, the WTRU 102 g shown in FIG.20 may be configured to communicate with the base station 114 a, whichmay employ a cellular-based radio technology, and with the base station114 c, which may employ an IEEE 802 radio technology.

Although not shown in FIG. 20 , it will be appreciated that a UserEquipment may make a wired connection to a gateway. The gateway maybe aResidential Gateway (RG). The RG may provide connectivity to a CoreNetwork 106/107/109. It will be appreciated that many of the ideascontained herein may equally apply to UEs that are WTRUs and UEs thatuse a wired connection to connect to a network. For example, the ideasthat apply to the wireless interfaces 115, 116, 117 and 115 c/116 c/117c may equally apply to a wired connection.

FIG. 21 is a system diagram of an example RAN 103 and core network 106.As noted above, the RAN 103 may employ a UTRA radio technology tocommunicate with the WTRUs 102 a, 102 b, and 102 c over the airinterface 115. The RAN 103 may also be in communication with the corenetwork 106. As shown in FIG. 21 , the RAN 103 may include Node-Bs 140a, 140 b, and 140 c, which may each include one or more transceivers forcommunicating with the WTRUs 102 a, 102 b, and 102 c over the airinterface 115. The Node-Bs 140 a, 140 b, and 140 c may each beassociated with a particular cell (not shown) within the RAN 103. TheRAN 103 may also include RNCs 142 a, 142 b. It will be appreciated thatthe RAN 103 may include any number of Node-Bs and Radio NetworkControllers (RNCs.)

As shown in FIG. 21 , the Node-Bs 140 a, 140 b may be in communicationwith the RNC 142 a. Additionally, the Node-B 140 c may be incommunication with the RNC 142 b. The Node-Bs 140 a, 140 b, and 140 cmay communicate with the respective RNCs 142 a and 142 b via an Iubinterface. The RNCs 142 a and 142 b may be in communication with oneanother via an Iur interface. Each of the RNCs 142 a and 142 b may beconfigured to control the respective Node-Bs 140 a, 140 b, and 140 c towhich it is connected. In addition, each of the RNCs 142 a and 142 b maybe configured to carry out or support other functionality, such as outerloop power control, load control, admission control, packet scheduling,handover control, macro-diversity, security functions, data encryption,and the like.

The core network 106 shown in FIG. 21 may include a media gateway (MGW)144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node(SGSN) 148, and/or a Gateway GPRS Support Node (GGSN) 150. While each ofthe foregoing elements are depicted as part of the core network 106, itwill be appreciated that any one of these elements may be owned and/oroperated by an entity other than the core network operator.

The RNC 142 a in the RAN 103 may be connected to the MSC 146 in the corenetwork 106 via an IuCS interface. The MSC 146 may be connected to theMGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102 a, 102 b,and 102 c with access to circuit-switched networks, such as the PSTN108, to facilitate communications between the WTRUs 102 a, 102 b, and102 c, and traditional land-line communications devices.

The RNC 142 a in the RAN 103 may also be connected to the SGSN 148 inthe core network 106 via an IuPS interface. The SGSN 148 may beconnected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide theWTRUs 102 a, 102 b, and 102 c with access to packet-switched networks,such as the Internet 110, to facilitate communications between and theWTRUs 102 a, 102 b, and 102 c, and IP-enabled devices.

The core network 106 may also be connected to the other networks 112,which may include other wired or wireless networks that are owned and/oroperated by other service providers.

FIG. 22 is a system diagram of an example RAN 104 and core network 107.As noted above, the RAN 104 may employ an E-UTRA radio technology tocommunicate with the WTRUs 102 a, 102 b, and 102 c over the airinterface 116. The RAN 104 may also be in communication with the corenetwork 107.

The RAN 104 may include eNode-Bs 160 a, 160 b, and 160 c, though it willbe appreciated that the RAN 104 may include any number of eNode-Bs. TheeNode-Bs 160 a, 160 b, and 160 c may each include one or moretransceivers for communicating with the WTRUs 102 a, 102 b, and 102 cover the air interface 116. For example, the eNode-Bs 160 a, 160 b, and160 c may implement MIMO technology. Thus, the eNode-B 160 a, forexample, may use multiple antennas to transmit wireless signals to, andreceive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 160 a, 160 b, and 160 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 22 , theeNode-Bs 160 a, 160 b, and 160 c may communicate with one another overan X2 interface.

The core network 107 shown in FIG. 22 may include a Mobility ManagementGateway (MME) 162, a serving gateway 164, and a Packet Data Network(PDN) gateway 166. While each of the foregoing elements are depicted aspart of the core network 107, it will be appreciated that any one ofthese elements may be owned and/or operated by an entity other than thecore network operator.

The MME 162 may be connected to each of the eNode-Bs 160 a, 160 b, and160 c in the RAN 104 via an S1 interface and may serve as a controlnode. For example, the MME 162 may be responsible for authenticatingusers of the WTRUs 102 a, 102 b, and 102 c, beareractivation/deactivation, selecting a particular serving gateway duringan initial attach of the WTRUs 102 a, 102 b, and 102 c, and the like.The MME 162 may also provide a control plane function for switchingbetween the RAN 104 and other RANs (not shown) that employ other radiotechnologies, such as GSM or WCDMA.

The serving gateway 164 may be connected to each of the eNode-Bs 160 a,160 b, and 160 c in the RAN 104 via the S1 interface. The servinggateway 164 may generally route and forward user data packets to/fromthe WTRUs 102 a, 102 b, and 102 c. The serving gateway 164 may alsoperform other functions, such as anchoring user planes duringinter-eNode B handovers, triggering paging when downlink data isavailable for the WTRUs 102 a, 102 b, and 102 c, managing and storingcontexts of the WTRUs 102 a, 102 b, and 102 c, and the like.

The serving gateway 164 may also be connected to the PDN gateway 166,which may provide the WTRUs 102 a, 102 b, and 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c, and IP-enableddevices.

The core network 107 may facilitate communications with other networks.For example, the core network 107 may provide the WTRUs 102 a, 102 b,and 102 c with access to circuit-switched networks, such as the PSTN108, to facilitate communications between the WTRUs 102 a, 102 b, and102 c and traditional land-line communications devices. For example, thecore network 107 may include, or may communicate with, an IP gateway(e.g., an IP Multimedia Subsystem (IMS) server) that serves as aninterface between the core network 107 and the PSTN 108. In addition,the core network 107 may provide the WTRUs 102 a, 102 b, and 102 c withaccess to the networks 112, which may include other wired or wirelessnetworks that are owned and/or operated by other service providers.

FIG. 23 is a system diagram of an example RAN 105 and core network 109.The RAN 105 may employ an NR radio technology to communicate with theWTRUs 102 a and 102 b over the air interface 117. The RAN 105 may alsobe in communication with the core network 109. A Non-3GPP InterworkingFunction (N3IWF) 199 may employ a non-3GPP radio technology tocommunicate with the WTRU 102 c over the air interface 198. The N3IWF199 may also be in communication with the core network 109.

The RAN 105 may include gNode-Bs 180 a and 180 b. It will be appreciatedthat the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180 aand 180 b may each include one or more transceivers for communicatingwith the WTRUs 102 a and 102 b over the air interface 117. Whenintegrated access and backhaul connection are used, the same airinterface may be used between the WTRUs and gNode-Bs, which may be thecore network 109 via one or multiple gNBs. The gNode-Bs 180 a and 180 bmay implement MIMO, MU-MIMO, and/or digital beamforming technology.Thus, the gNode-B 180 a, for example, may use multiple antennas totransmit wireless signals to, and receive wireless signals from, theWTRU 102 a. It should be appreciated that the RAN 105 may employ othertypes of base stations such as an eNode-B. It will also be appreciatedthe RAN 105 may employ more than one type of base station. For example,the RAN may employ eNode-Bs and gNode-Bs.

The N3IWF 199 may include a non-3GPP Access Point 180 c. It will beappreciated that the N3IWF 199 may include any number of non-3GPP AccessPoints. The non-3GPP Access Point 180 c may include one or moretransceivers for communicating with the WTRUs 102 c over the airinterface 198. The non-3GPP Access Point 180 c may use the 802.11protocol to communicate with the WTRU 102 c over the air interface 198.

Each of the gNode-Bs 180 a and 180 b may be associated with a particularcell (not shown) and may be configured to handle radio resourcemanagement decisions, handover decisions, scheduling of users in theuplink and/or downlink, and the like. As shown in FIG. 23 , the gNode-Bs180 a and 180 b may communicate with one another over an Xn interface,for example.

The core network 109 shown in FIG. 23 may be a 5G core network (5GC).The core network 109 may offer numerous communication services tocustomers who are interconnected by the radio access network. The corenetwork 109 comprises a number of entities that perform thefunctionality of the core network. As used herein, the term “corenetwork entity” or “network function” refers to any entity that performsone or more functionalities of a core network. It is understood thatsuch core network entities may be logical entities that are implementedin the form of computer-executable instructions (software) stored in amemory of, and executing on a processor of, an apparatus configured forwireless and/or network communications or a computer system, such assystem 90 illustrated in FIG. 26 .

In the example of FIG. 23 , the 5G Core Network 109 may include anaccess and mobility management function (AMF) 172, a Session ManagementFunction (SMF) 174, User Plane Functions (UPFs) 176 a and 176 b, a UserData Management Function (UDM) 197, an Authentication Server Function(AUSF) 190, a Network Exposure Function (NEF) 196, a Policy ControlFunction (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, a UserData Repository (UDR) 178. While each of the foregoing elements aredepicted as part of the 5G core network 109, it will be appreciated thatany one of these elements may be owned and/or operated by an entityother than the core network operator. It will also be appreciated that a5G core network may not consist of all of these elements, may consist ofadditional elements, and may consist of multiple instances of each ofthese elements. FIG. 23 shows that network functions directly connect toone another, however, it should be appreciated that they may communicatevia routing agents such as a diameter routing agent or message buses.

In the example of FIG. 23 , connectivity between network functions isachieved via a set of interfaces, or reference points. It will beappreciated that network functions could be modeled, described, orimplemented as a set of services that are invoked, or called, by othernetwork functions or services. Invocation of a Network Function servicemay be achieved via a direct connection between network functions, anexchange of messaging on a message bus, calling a software function,etc.

The AMF 172 may be connected to the RAN 105 via an N2 interface and mayserve as a control node. For example, the AMF 172 may be responsible forregistration management, connection management, reachability management,access authentication, access authorization. The AMF may be responsibleforwarding user plane tunnel configuration information to the RAN 105via the N2 interface. The AMF 172 may receive the user plane tunnelconfiguration information from the SMF via an N11 interface. The AMF 172may generally route and forward NAS packets to/from the WTRUs 102 a, 102b, and 102 c via an N1 interface. The N1 interface is not shown in FIG.23 .

The SMF 174 may be connected to the AMF 172 via an N11 interface.Similarly the SMF may be connected to the PCF 184 via an N7 interface,and to the UPFs 176 a and 176 b via an N4 interface. The SMF 174 mayserve as a control node. For example, the SMF 174 may be responsible forSession Management, IP address allocation for the WTRUs 102 a, 102 b,and 102 c, management and configuration of traffic steering rules in theUPF 176 a and UPF 176 b, and generation of downlink data notificationsto the AMF 172.

The UPF 176 a and UPF 176 b may provide the WTRUs 102 a, 102 b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110,to facilitate communications between the WTRUs 102 a, 102 b, and 102 cand other devices. The UPF 176 a and UPF 176 b may also provide theWTRUs 102 a, 102 b, and 102 c with access to other types of packet datanetworks. For example, Other Networks 112 may be Ethernet Networks orany type of network that exchanges packets of data. The UPF 176 a andUPF 176 b may receive traffic steering rules from the SMF 174 via the N4interface. The UPF 176 a and UPF 176 b may provide access to a packetdata network by connecting a packet data network with an N6 interface orby connecting to each other and to other UPFs via an N9 interface. Inaddition to providing access to packet data networks, the UPF 176 may beresponsible packet routing and forwarding, policy rule enforcement,quality of service handling for user plane traffic, downlink packetbuffering.

The AMF 172 may also be connected to the N3IWF 199, for example, via anN2 interface. The N3IWF facilitates a connection between the WTRU 102 cand the 5G core network 170, for example, via radio interfacetechnologies that are not defined by 3GPP. The AMF may interact with theN3IWF 199 in the same, or similar, manner that it interacts with the RAN105.

The PCF 184 may be connected to the SMF 174 via an N7 interface,connected to the AMF 172 via an N15 interface, and to an ApplicationFunction (AF) 188 via an N5 interface. The N15 and N5 interfaces are notshown in FIG. 23 . The PCF 184 may provide policy rules to control planenodes such as the AMF 172 and SMF 174, allowing the control plane nodesto enforce these rules. The PCF 184, may send policies to the AMF 172for the WTRUs 102 a, 102 b, and 102 c so that the AMF may deliver thepolicies to the WTRUs 102 a, 102 b, and 102 c via an N1 interface.Policies may then be enforced, or applied, at the WTRUs 102 a, 102 b,and 102 c.

The UDR 178 may act as a repository for authentication credentials andsubscription information. The UDR may connect to network functions, sothat network function can add to, read from, and modify the data that isin the repository. For example, the UDR 178 may connect to the PCF 184via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196via an N37 interface, and the UDR 178 may connect to the UDM 197 via anN35 interface.

The UDM 197 may serve as an interface between the UDR 178 and othernetwork functions. The UDM 197 may authorize network functions to accessof the UDR 178. For example, the UDM 197 may connect to the AMF 172 viaan N8 interface, the UDM 197 may connect to the SMF 174 via an N10interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13interface. The UDR 178 and UDM 197 may be tightly integrated.

The AUSF 190 performs authentication related operations and connects tothe UDM 178 via an N13 interface and to the AMF 172 via an N12interface.

The NEF 196 exposes capabilities and services in the 5G core network 109to Application Functions (AF) 188. Exposure may occur on the N33 APIinterface. The NEF may connect to an AF 188 via an N33 interface and itmay connect to other network functions in order to expose thecapabilities and services of the 5G core network 109.

Application Functions 188 may interact with network functions in the 5GCore Network 109. Interaction between the Application Functions 188 andnetwork functions may be via a direct interface or may occur via the NEF196. The Application Functions 188 may be considered part of the 5G CoreNetwork 109 or may be external to the 5G Core Network 109 and deployedby enterprises that have a business relationship with the mobile networkoperator.

Network Slicing is a mechanism that could be used by mobile networkoperators to support one or more ‘virtual’ core networks behind theoperator's air interface. This involves ‘slicing’ the core network intoone or more virtual networks to support different RANs or differentservice types running across a single RAN. Network slicing enables theoperator to create networks customized to provide optimized solutionsfor different market scenarios which demands diverse requirements, e.g.in the areas of functionality, performance and isolation.

3GPP has designed the 5G core network to support Network Slicing.Network Slicing is a good tool that network operators can use to supportthe diverse set of 5G use cases (e.g., massive IoT, criticalcommunications, V2X, and enhanced mobile broadband) which demand verydiverse and sometimes extreme requirements. Without the use of networkslicing techniques, it is likely that the network architecture would notbe flexible and scalable enough to efficiently support a wider range ofuse cases need when each use case has its own specific set ofperformance, scalability, and availability requirements. Furthermore,introduction of new network services should be made more efficient.

Referring again to FIG. 23 , in a network slicing scenario, a WTRU 102a, 102 b, or 102 c may connect to an AMF 172, via an N1 interface. TheAMF may be logically part of one or more slices. The AMF may coordinatethe connection or communication of WTRU 102 a, 102 b, or 102 c with oneor more UPF 176 a and 176 b, SMF 174, and other network functions. Eachof the UPFs 176 a and 176 b, SMF 174, and other network functions may bepart of the same slice or different slices. When they are part ofdifferent slices, they may be isolated from each other in the sense thatthey may utilize different computing resources, security credentials,etc.

The core network 109 may facilitate communications with other networks.For example, the core network 109 may include, or may communicate with,an IP gateway, such as an IP Multimedia Subsystem (IMS) server, thatserves as an interface between the 5G core network 109 and a PSTN 108.For example, the core network 109 may include, or communicate with ashort message service (SMS) service center that facilities communicationvia the short message service. For example, the 5G core network 109 mayfacilitate the exchange of non-IP data packets between the WTRUs 102 a,102 b, and 102 c and servers or applications functions 188. In addition,the core network 170 may provide the WTRUs 102 a, 102 b, and 102 c withaccess to the networks 112, which may include other wired or wirelessnetworks that are owned and/or operated by other service providers.

The core network entities described herein and illustrated in FIGS. 20,22, 23, and 24 are identified by the names given to those entities incertain existing 3GPP specifications, but it is understood that in thefuture those entities and functionalities may be identified by othernames and certain entities or functions may be combined in futurespecifications published by 3GPP, including future 3GPP NRspecifications. Thus, the particular network entities andfunctionalities described and illustrated in FIGS. 20, 21, 22, 23, and24 are provided by way of example only, and it is understood that thesubject matter disclosed and claimed herein may be embodied orimplemented in any similar communication system, whether presentlydefined or defined in the future.

FIG. 24 illustrates an example communications system 111 in which thesystems, methods, apparatuses described herein may be used.Communications system 111 may include Wireless Transmit/Receive Units(WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, andRoad Side Units (RSUs) 123 a and 123 b. In practice, the conceptspresented herein may be applied to any number of WTRUs, base stationgNBs, V2X networks, and/or other network elements. One or several or allWTRUs A, B, C, D, E, and F may be out of range of the access networkcoverage 131. WTRUs A, B, and C form a V2X group, among which WTRU A isthe group lead and WTRUs B and C are group members.

WTRUs A, B, C, D, E, and F may communicate with each other over a Uuinterface 129 via the gNB 121 if they are within the access networkcoverage 131. In the example of FIG. 24 , WTRUs B and F are shown withinaccess network coverage 131. WTRUs A, B, C, D, E, and F may communicatewith each other directly via a Sidelink interface (e.g., PC5 or NR PC5)such as interface 125 a, 125 b, or 128, whether they are under theaccess network coverage 131 or out of the access network coverage 131.For instance, in the example of FIG. 24 , WRTU D, which is outside ofthe access network coverage 131, communicates with WTRU F, which isinside the coverage 131.

WTRUs A, B, C, D, E, and F may communicate with RSU 123 a or 123 b via aVehicle-to-Network (V2N) 133 or Sidelink interface 125 b. WTRUs A, B, C,D, E, and F may communicate to a V2X Server 124 via aVehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, andF may communicate to another UE via a Vehicle-to-Person (V2P) interface128.

FIG. 25 is a block diagram of an example apparatus or device WTRU 102that may be configured for wireless communications and operations inaccordance with the systems, methods, and apparatuses described herein,such as a WTRU 102 of FIG. 20, 21, 22, 23 , or 24. As shown in FIG. 25 ,the example WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad/indicators 128, non-removable memory 130, removablememory 132, a power source 134, a global positioning system (GPS)chipset 136, and other peripherals 138. It will be appreciated that theWTRU 102 may include any sub-combination of the foregoing elements.Also, the base stations 114 a and 114 b, and/or the nodes that basestations 114 a and 114 b may represent, such as but not limited totransceiver station (BTS), a Node-B, a site controller, an access point(AP), a home node-B, an evolved home node-B (eNodeB), a home evolvednode-B (HeNB), a home evolved node-B gateway, a next generation node-B(gNode-B), and proxy nodes, among others, may include some or all of theelements depicted in FIG. 25 and described herein.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 25depicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 of a UE may be configured to transmitsignals to, or receive signals from, a base station (e.g., the basestation 114 a of FIG. 20 ) over the air interface 115/116/117 or anotherUE over the air interface 115 d/116 d/117 d. For example, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. The transmit/receive element 122 may be anemitter/detector configured to transmit and/or receive IR, UV, orvisible light signals, for example. The transmit/receive element 122 maybe configured to transmit and receive both RF and light signals. It willbe appreciated that the transmit/receive element 122 may be configuredto transmit and/or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 25 as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, the WTRU 102 may include two or moretransmit/receive elements 122 (e.g., multiple antennas) for transmittingand receiving wireless signals over the air interface 115/116/117.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, for example NR and IEEE 802.11 orNR and E-UTRA, or to communicate with the same RAT via multiple beams todifferent RRHs, TRPs, RSUs, or nodes.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad/indicators 128 (e.g., a liquid crystal display(LCD) display unit or organic light-emitting diode (OLED) display unit.The processor 118 may also output user data to the speaker/microphone124, the keypad 126, and/or the display/touchpad/indicators 128. Inaddition, the processor 118 may access information from, and store datain, any type of suitable memory, such as the non-removable memory 130and/or the removable memory 132. The non-removable memory 130 mayinclude random-access memory (RAM), read-only memory (ROM), a hard disk,or any other type of memory storage device. The removable memory 132 mayinclude a subscriber identity module (SIM) card, a memory stick, asecure digital (SD) memory card, and the like. The processor 118 mayaccess information from, and store data in, memory that is notphysically located on the WTRU 102, such as on a server that is hostedin the cloud or in an edge computing platform or in a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries, solar cells, fuel cells, and thelike.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 115/116/117from a base station (e.g., base stations 114 a, 114 b) and/or determineits location based on the timing of the signals being received from twoor more nearby base stations. It will be appreciated that the WTRU 102may acquire location information by way of any suitablelocation-determination method.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality, and/or wired or wirelessconnectivity. For example, the peripherals 138 may include varioussensors such as an accelerometer, biometrics (e.g., finger print)sensors, an e-compass, a satellite transceiver, a digital camera (forphotographs or video), a universal serial bus (USB) port or otherinterconnect interfaces, a vibration device, a television transceiver, ahands free headset, a Bluetooth® module, a frequency modulated (FM)radio unit, a digital music player, a media player, a video game playermodule, an Internet browser, and the like.

The WTRU 102 may be included in other apparatuses or devices, such as asensor, consumer electronics, a wearable device such as a smart watch orsmart clothing, a medical or eHealth device, a robot, industrialequipment, a drone, a vehicle such as a car, truck, train, or anairplane. The WTRU 102 may connect to other components, modules, orsystems of such apparatuses or devices via one or more interconnectinterfaces, such as an interconnect interface that may comprise one ofthe peripherals 138.

FIG. 26 is a block diagram of an exemplary computing system 90 in whichone or more apparatuses of the communications networks illustrated inFIGS. 20, 22, 23 and 24 may be embodied, such as certain nodes orfunctional entities in the RAN 103/104/105, Core Network 106/107/109,PSTN 108, Internet 110, Other Networks 112, or Network Services 113.Computing system 90 may comprise a computer or server and may becontrolled primarily by computer readable instructions, which may be inthe form of software, wherever, or by whatever means such software isstored or accessed. Such computer readable instructions may be executedwithin a processor 91, to cause computing system 90 to do work. Theprocessor 91 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 91 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the computing system 90 to operate in acommunications network. Coprocessor 81 is an optional processor,distinct from main processor 91, that may perform additional functionsor assist processor 91. Processor 91 and/or coprocessor 81 may receive,generate, and process data related to the methods and apparatusesdisclosed herein.

In operation, processor 91 fetches, decodes, and executes instructions,and transfers information to and from other resources via the computingsystem's main data-transfer path, system bus 80. Such a system busconnects the components in computing system 90 and defines the mediumfor data exchange. System bus 80 typically includes data lines forsending data, address lines for sending addresses, and control lines forsending interrupts and for operating the system bus. An example of sucha system bus 80 is the PCI (Peripheral Component Interconnect) bus.

Memories coupled to system bus 80 include random access memory (RAM) 82and read only memory (ROM) 93. Such memories include circuitry thatallows information to be stored and retrieved. ROMs 93 generally containstored data that cannot easily be modified. Data stored in RAM 82 may beread or changed by processor 91 or other hardware devices. Access to RAM82 and/or ROM 93 may be controlled by memory controller 92. Memorycontroller 92 may provide an address translation function thattranslates virtual addresses into physical addresses as instructions areexecuted. Memory controller 92 may also provide a memory protectionfunction that isolates processes within the system and isolates systemprocesses from user processes. Thus, a program running in a first modemay access only memory mapped by its own process virtual address space;it cannot access memory within another process's virtual address spaceunless memory sharing between the processes has been set up.

In addition, computing system 90 may contain peripherals controller 83responsible for communicating instructions from processor 91 toperipherals, such as printer 94, keyboard 84, mouse 95, and disk drive85.

Display 86, which is controlled by display controller 96, is used todisplay visual output generated by computing system 90. Such visualoutput may include text, graphics, animated graphics, and video. Thevisual output may be provided in the form of a graphical user interface(GUI). Display 86 may be implemented with a CRT-based video display, anLCD-based flat-panel display, gas plasma-based flat-panel display, or atouch-panel. Display controller 96 includes electronic componentsrequired to generate a video signal that is sent to display 86.

Further, computing system 90 may contain communication circuitry, suchas for example a wireless or wired network adapter 97, that may be usedto connect computing system 90 to an external communications network ordevices, such as the RAN 103/104/105, Core Network 106/107/109, PSTN108, Internet 110, WTRUs 102, or Other Networks 112 of FIGS. 20, 21, 22,23, and 24 , to enable the computing system 90 to communicate with othernodes or functional entities of those networks. The communicationcircuitry, alone or in combination with the processor 91, may be used toperform the transmitting and receiving steps of certain apparatuses,nodes, or functional entities described herein.

It is understood that any or all of the apparatuses, systems, methodsand processes described herein may be embodied in the form of computerexecutable instructions (e.g., program code) stored on acomputer-readable storage medium which instructions, when executed by aprocessor, such as processors 118 or 91, cause the processor to performand/or implement the systems, methods and processes described herein.Specifically, any of the steps, operations, or functions describedherein may be implemented in the form of such computer executableinstructions, executing on the processor of an apparatus or computingsystem configured for wireless and/or wired network communications.Computer readable storage media includes volatile and nonvolatile,removable and non-removable media implemented in any non-transitory(e.g., tangible or physical) method or technology for storage ofinformation, but such computer readable storage media do not includesignals. Computer readable storage media include, but are not limitedto, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disks (DVD) or other optical disk storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other tangible or physical medium which may beused to store the desired information and which may be accessed by acomputing system.

We claim:
 1. An apparatus comprising a processor, a memory, andcommunication circuitry, the apparatus configured to communicate via thecommunication circuitry, the apparatus further comprisingcomputer-executable instructions stored in the memory of the apparatuswhich, when executed by the processor of the apparatus, cause theapparatus to: receive, from a first network, system information, thesystem information relating to network support for restricted access fornetwork selection assistance; send, to the first network, a registrationrequest, the registration request signaling a limited registration;receive, via the first network, network information from a server;de-register from the first network; and register with a second network.2. The apparatus of claim 1, wherein the registration request furthersignals support for non-coverage related network transfers.
 3. Theapparatus of claim 1, wherein the computer-executable instructionsfurther cause the apparatus to send a network selection request thatcomprises a list of found networks.
 4. The apparatus of claim 3, whereinthe second network is selected from the list of found networks.
 5. Theapparatus of claim 3, wherein the network selection request furthercomprises a received signal strength associated with each found network.6. The apparatus of claim 3, wherein the network selection requestfurther comprises a cell identity of a strongest cell associated witheach found network.
 7. The apparatus of claim 3, wherein the networkselection request is sent in a non-access-stratum message.
 8. Theapparatus of claim 3, wherein the network selection request is sent to apolicy control function.
 9. The apparatus of claim 3, wherein thenetwork selection request is sent to the server via a restricted localoperator services, RLOS, connection using Internet protocol, IP, basedcommunication.
 10. The apparatus of claim 3, wherein the registrationrequest includes information indicating the network selection request.11. The apparatus of claim 10, wherein the network information comprisesinformation indicating a network selection response.
 12. The apparatusof claim 11, wherein the network selection response comprises anindication of a time window to execute a registration to the secondnetwork.
 13. A method performed by an apparatus comprising a processorand a memory, the method comprising: receiving, from a first network,system information, the system information relating to network supportfor restricted access for network selection assistance; sending, to thefirst network, a registration request, the registration requestsignaling a limited registration; receive, via the first network,network information from a server; de-registering from the firstnetwork; and registering with a second network.
 14. The method of claim13, wherein the network information comprises an indication of a timewindow to execute a registration to the second network.
 15. The methodof claim 13, wherein the registration request further signals supportfor non-coverage related network transfers.
 16. The method of claim 13,further comprising sending a network selection request that comprises alist of found networks.
 17. The method of claim 16, wherein the secondnetwork is selected from the list of found networks.
 18. The method ofclaim 16, wherein the network selection request further comprises areceived signal strength associated with each found network.
 19. Themethod of claim 16, wherein the network selection request is sent in anon-access-stratum message.
 20. A non-transitory computer-readablestorage medium having stored thereon computer-executable instructions,which, upon execution by one or more processors, caused the one or moreprocessors to perform operations comprising: receiving, from a firstnetwork, system information, the system information relating to networksupport for restricted access for network selection assistance; sending,to the first network, a registration request, the registration requestsignaling a limited registration; receive, via the first network,network information from a server; de-registering from the firstnetwork; and registering with a second network.